The TSO/E OMVS command will allow users to start more than one session with the shell. Only one session is displayed at a time on the screen. The multi-session support in the shell allows these shell processes to reside as tasks in the same address space. The user can switch between different sessions using a PFK. The following OMVS, sub-commands to control the multi-session support. Those are open, which starts a new shell session. Close or quit, closes a shell session. Quit all, ends all sessions, and returns to TSO/E. Next sess switches to the next session and previous sess switches to the previous session. The non TSO/E user can log in to multiple shell sessions using the same user ID and password. You can also be logged onto the shell using the TSO/E interface and the login interface using the same user ID and password. Here's an example of a shell script with some logic. This example has a for loop for do, done. It also has an if condition that runs a sequence of commands if a particular condition is met, if then, FI. This example of a shell script takes one positional parameter giving the name of a file. The script looks in the working directory and finds the names of all.c files. The if control structure inside the for loop tests each file to see if it's older than the file name on the command line. If the.c file is older, echo displays the name and the file is compiled. What we've seen there is a shell script that has the capability to run a sequence of commands stored in a text file. The commands in the file can be run by entering the filename on the command line. After a shell script is created, a user needs read and execute permission to run the script. A shell is like a program made up of shell commands. The shell supports many of the features of regular programming languages like variables, control structures, and functions. A set of z/OS UNIX extensions to TSO/E REXX provides the capability for REXX execs to access z/OS UNIX callable services. The z/OS UNIX extensions direct are called syscall commands and they have names that correspond to the names of the callable services they invoke. For example, exec fork and pipe REXX execs using z/OS UNIX extensions can run from TSO/E or in z/OS batch and access the z/OS UNIX functions and services through a host command environment, rather than discrete external functions. The host command environment is called syscall. The environment must be initialized by a syscall on a statement in the beginning of the exec. Rexx execs can also be run in the z/OS UNIX shell or from a C program using the exec system call. This is different from shell scripts which are only interpreted in the shell. This also means that shell scripts can invoke a REXX exec, just like they would invoke any program. When running in REXX exec, in the shell, or from a C program, the syscall environment is automatically initialized. There are many ways in z/OS UNIX to send the message to another user. Which method to use depends on the requirements and the time-frames you want the message to be sent, such as logger and right. As a TSO/E user, you might prefer to just use facilities provided by TSO/E instead. The crocker daemon cron is a facility that allows you to run a command and its specific time. Run a command in batch when the system activity is low, or set up commands, scripts, or programs to run at the same time, every day or every week. Batch work is assigned bottom priority. The cron daemon examines the at batch or crontab fossa initialization or whenever they change and start the functions at the specified times. It uses the time zone in effect when the command is executed. Therefore, be sure to set the TZ environment variable before starting cron. In the next video, we'll look at BPX batch.